), change jobs,
etc. Unless you have a unique immutable identifier that's enforced by
some authority (like a social security number[1]), I don't think there
is a chance to do that reliably in a program (although with enough data,
a heuristic may be good enough).
hp
--
_ |
On 2022-04-03 23:17:04 +0200, Marco Sulla wrote:
> On Sun, 3 Apr 2022 at 21:46, Peter J. Holzer wrote:
> > > > data.get_deep("users", 0, "address", "street", default="second star")
> >
> > Yep. Did that, too. Plus pass the fin
On 2022-04-12 21:03:00 +0200, Marco Sulla wrote:
> On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote:
> > They are are about a year apart, so they will usually contain different
> > versions of most packages right from the start. So the Ubuntu and Debian
> > security
On 2022-04-14 19:31:58 +0200, Marco Sulla wrote:
> On Wed, 13 Apr 2022 at 20:05, Peter J. Holzer wrote:
> >
> > On 2022-04-12 21:03:00 +0200, Marco Sulla wrote:
> > > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote:
> > > > They are are about a year
║
╟╢
║ 2022-03-26 12:00:00+01 ║
╚╝
(1 row)
Time: 5.542 ms
hjp=> select '2022-03-26T12:00'::timestamptz + '1 day'::interval;
╔════════╗
║?column?║
╟╢
║ 2022-03-27 12:00:00+02 ║
╚═══
at's where they have to be for
the tools to find them (yes, this is on Ubuntu).
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp
On 2022-04-16 13:47:32 -, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer wrote:
> > On 2022-04-14 15:22:29 -, Jon Ribbens via Python-list wrote:
> >> On 2022-04-14, Paul Bryan wrote:
> >> > I think because minutes and hours can eas
On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Jon Ribbens wrote:
> > On 2022-04-16, Peter J. Holzer wrote:
> >> Python missed the switch to DST here, the timezone is wrong.
> >
> > Because you didn't let it use any timezone
On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote:
> > On the contrary. When a datetime is timezone aware, it must use that
> > timezone's rules. Adding one day to a datetime just before a DST switch
> > must add 23
e between to datetimes as a
timedeltacal. It could be a method on datetime (maybe t.sub(u) for t-u
like in Go) or a constructor which takes two datetime objects.
In any case I think that u + (t - u) == t should hold. [TODO: Check that
this is possible]
hp
--
_ | Peter J. Holzer
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> > > So which one is it? Which one do you get when you add days=7 to a
> > > datetime?
> >
> >
On 2022-04-16 19:35:51 +0200, Peter J. Holzer wrote:
> Note that t + d - d is in general not equal to t.
>
> We can't cnange the semantics of datetime - datetime, so there must be a
> function to compute the difference between to datetimes as a
> timedeltacal. It could be
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > For adding a datetime and timedelta I think the answer is clear.
> > But subtracting two datetimes is ambiguous.
> >
>
> But if the difference between two dat
(The one aspect that isn't hidden is of course the set of characters
that you can store in a character field: Obviously, you can't store
Chinese characters in a latin1 field).
If you are using Python2, manual encoding and decoding may be necessary.
(AFAICS the OP still hasn't state
methods are about equally
secure: If you can become the daemon user (or root), then you can read
the secret.
(Historically, many unixes allowed all users to read the environment
variables of all processes. I don't know if this is still the case for
e.g. Solaris or AIX - or macOS)
hp
--
On 2018-03-25 06:30:54 +1100, Chris Angelico wrote:
> On Sun, Mar 25, 2018 at 3:35 AM, Peter J. Holzer wrote:
> > On 2018-03-24 11:21:09 +1100, Chris Angelico wrote:
> >> If the database has been configured to use UTF-8 (as mentioned, that's
> >> "utf8mb
on (as you stated).
That is still there, but in addition you now split the string into a
list and then join the list into a different string.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophistica
s additional operations on the string. So it is slower and harder
to understand than what you already had. (It also cannot be properly
indented, but you may not care about that.)
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) |
; better called "5000".
If Python 4.0 will "merely be the release that comes after Python
3.9", as Nick Coghlan writes in
https://opensource.com/life/14/9/why-python-4-wont-be-python-3, why will
it be called 4.0 and not 3.10? Just to avoid two-digit minor numbers?
hp
.
> This was not as Intel intended, but a quite cheap consumer grade
> hardware solution.
My dual pentium wasn't cheap, but the motherboard and the second
processor weren't that expensive. The 21" monitor OTOH ...
and did it have a tape drive? I don't remember, but I
On 2018-03-25 22:52:59 +, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote:
> >> >> By the way, multiple CPU machines are different from CPUs with
> >> >> multiple cores:
> >> >>
> >> >>
gt; L'Policy ID 243"|
> []
> []
> []
> []
> []
> []
> []
> []
> {'log count 777,"]
>
>
>
> How so I fix the code sone that it does not print empty []
Print the result only if findall actually found something.
hp
only correct if the internal representation is
binary - in general you don't unexpected rounding errors if the base of
the internal representation and the base of the literal match, and you
do get unexpected rounding errors if they don't)
hp
--
_ | Peter J. Holzer| we b
s new object. The old str object isn't needed anymore and
destroyed.
> >>> obj
> ['a', '1', 'b', '2']
> >>> type (obj)
>
> >>>
> >>> obj = dict( zip(obj[0::2],obj[1::2]) )
And here you create another new object
what that would prove.)
OTOH, despite having used C and Perl long before Python, I don't miss
assignment expressions. Every language has its idioms, and just because
you write stuff like “if ((fd = open(...)) == -1)” a lot in C doesn't
mean you have to be able to write that
On 2018-05-16 00:04:06 +, Steven D'Aprano wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
> > On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
> [...]
> >> By 1991 there had already been *decades* of experience with C
> >
> &
On 2018-05-16 01:26:38 +0100, bartc wrote:
> On 15/05/2018 21:21, Peter J. Holzer wrote:
> > I have been programming in C since the mid-80's and in Perl since the
> > mid-90's (both languages allow assignment expressions). I accumulated my
> > fair share of bugs in t
On 2018-05-19 11:38:09 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" :
> > (I wonder whether the notion that “=” and “==” are easy to mix up
> > stems from the early days of C when C was an outlier (most other
> > languages at the time used “=” for equality). N
ich lets me process individual bytes easily. That would even work on
both ASCII and EBCDIC based systems (and on every other platform, too).
> But then you are acknowledging the file is, in fact, ASCII.
No need to acknowledge anything. Yes. the inventor of the format was
obviously thinking i
On 2018-05-19 13:43:14 +0100, bartc wrote:
> On 19/05/2018 12:33, Peter J. Holzer wrote:
> > On 2018-05-19 11:33:26 +0100, bartc wrote:
>
> > > Not you understand why some of us don't bother with 'text mode' files.
> >
> > "Not" or &qu
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
signature.asc
Descripti
on ASCII or EBCDIC systems, on systems where 1 byte is
more than 8 bits (as long as the file stores still one octet per byte),
etc.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |
h version and all previous upgrades used the version
field).
Of course, if a popular implementation has known bugs you may have no
choice but make concessions.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have muc
hey may not be aware that the file is converted
somewhere in the pipeline, to that the file they generated isn't
actually the file you received. So ask (or check the docs), but
verify!
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) |
On 2018-05-22 20:42:43 +, Grant Edwards wrote:
> On 2018-05-22, Peter J. Holzer wrote:
> > On 2018-05-21 15:42:28 +, Grant Edwards wrote:
> >> I switched from Usenet to Gmane mainly because references headers are
> >> bit more consistent on Gmane, so thre
On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> On Wed, May 23, 2018 at 7:23 AM, Peter J. Holzer wrote:
> >> The best you can do is to go ask the canonical source of the
> >> file what encoding the file is _supposed_ to be in.
> >
> > I disagree on both coun
kely that I
was mistaken and that it the gateway at uni-berlin.de all along.
I apologize for attributing the error to Gmane.
Are the persons running the gateway reading this list? Could you please
fix this? Changing message-ids is an absolute no-no.
hp
--
_ | Peter J.
aligned vertically.
* The contents of the string must be indented at least as far as the
delimiters (and with consistent tabs/spaces).
This leading white space is ignored.
* All the leading white space beyond this 'left edge' is preserved.
* The newlines after the leading '&#
On 2018-05-23 08:43:02 +1000, Chris Angelico wrote:
> On Wed, May 23, 2018 at 8:31 AM, Peter J. Holzer wrote:
> > On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> >> > 1) For any given file it is almost always possible to find the correct
> >> >encoding (
On 2018-05-23 06:03:38 +, Steven D'Aprano wrote:
> On Wed, 23 May 2018 00:31:03 +0200, Peter J. Holzer wrote:
> > On 2018-05-23 07:38:27 +1000, Chris Angelico wrote:
> >> You can find an encoding which is capable of decoding a file. That's
> >> not the
On 2018-05-23 11:08:48 -0600, Ian Kelly wrote:
> On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer wrote:
> > How about this?
> >
> > x = ''''
> > Here is a multi-line string
> > with
> > indent
tomatically, and possibly with
higher reliability than a human can (many captchas are hard and
frustrating for humans).
It *is* an arms race and who wins depends on who where to break-even
point between effort and value is for the defender and the attacker.
hp
--
_ | Peter J. Hol
at show should call xdg-open preferentially and maybe fall
back to display. And of course silently ignoring a documented parameter
is clearly a bug (if it's true - I notice that the Pillow docs don't mention
that parameter and the original PIL seems to unmaintained).
hp
[1] Whi
fter a few months ;-).
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
On 2018-05-29 19:46:24 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 6:15 PM, Peter J. Holzer wrote:
> > So if the text is German it will contain more words with
> > umlauts and each byte which is part of a correctly spelled German word
> > when interpreted ac
On 2018-05-29 19:47:37 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 6:34 PM, Peter J. Holzer wrote:
> > On 2018-05-23 06:03:38 +, Steven D'Aprano wrote:
> >> Mojibake is especially difficult to deal with when you are dealing with
> >> short text
On 2018-05-29 20:28:54 +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 8:09 PM, Peter J. Holzer wrote:
> > On 2018-05-29 19:46:24 +1000, Chris Angelico wrote:
> >> That's basically what the chardet module does, and its error rate is
> >> far FAR higher than
e probably can't distinguish Korean poetry from a Vietnamese
shopping list, but his file probably isn't either.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hj
gick
isn't a viewer, it is a collection of programs for manipulating images.
The viewer included in the ImageMagick package is simply called
'display' (and it is already the default viewer in PIL, so you don't
have to do anything to use it).
hp
On 2018-05-30 07:45:07 +0200, dieter wrote:
> "Peter J. Holzer" writes:
> > On 2018-05-26 07:38:09 +0200, dieter wrote:
> >> But, in general, you are right: you cannot reconstruct complete
> >> call trees. The reason is quite simple: maintaining information
904076730672386474907398223876953125, but that needs a
few bits too much, so it rounded down to
1016.8863131622783839702606201171875.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more so
ltered for
some reason.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.o
On 2018-05-29 16:20:36 +, Steven D'Aprano wrote:
> On Tue, 29 May 2018 14:04:19 +0200, Peter J. Holzer wrote:
>
> > The OP has one file.
>
> We don't know that. All we know is that he had one file which he was
> unable to read. For all we know, he ha
On 2018-05-29 07:57:18 -0600, Ian Kelly wrote:
> On Tue, May 29, 2018 at 3:19 AM, Peter J. Holzer wrote:
> > On 2018-05-23 11:08:48 -0600, Ian Kelly wrote:
> >>
[...]
> > What if I want all lines to start with some white space?
[...]
>
> Fair points.
[...]
>
ll its messages from the mailing list. Since Paul's
message didn't make it to the mailing list, it didn't make it to gmane
either.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophist
bably not much of a restriction in
practice).
> If this is an iterable, the numbers returned from each iteration
> will be used for their respective lines. If there are more lines
> than iterations, the last iteration will be used for subsequent
> lines.
This looks li
Test = """
|Hello, this is a
| Multiline indented
|String
""".outdent(padding='|')
Or write it like this?
Test = """|Hello, this is a
| Multiline indented
|String
On 2018-05-31 23:05:35 +0200, Peter J. Holzer wrote:
> [Strange: I didn't get this mail through the list, only directly]
Found it. For some reason "Avoid duplicate copies of messages" was
enabled. I normally always disable this when I subscribe to a
mailinglist and I'm s
ilinglist software can probably distinguish between
multipart/signed and multipart/mixed.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hjp.at | management tools.
_
On 2018-06-02 07:59:07 +1000, Chris Angelico wrote:
> On Sat, Jun 2, 2018 at 7:03 AM, Peter J. Holzer wrote:
> > On 2018-05-31 14:42:39 -0700, Paul wrote:
> >> I have heard that attachments to messages are not allowed on this list,
> >> which makes sense. However I noti
st mess up sorting in an unpredictable
way. Is this the intended behaviour or just an accident of
implementation? (I think it's the latter: I can see how a sort algorithm
which doesn't treat NaN specially would produce such results.)
hp
--
_ | Peter J. Holzer| we bu
uot;/tmp/foo" to the libc (there happen to be more bytes after the
terminator, but they are not part of the string as far as libc is
concerned), which is not the same as "/tmp/foo\x00bar".
So that has to be handled by Python before calling libc.
hp
--
_ | Peter J. H
On 2018-06-02 10:40:48 +, Steven D'Aprano wrote:
> On Sat, 02 Jun 2018 09:32:05 +0200, Peter J. Holzer wrote:
> > Also nope. It looks like NaNs just mess up sorting in an unpredictable
> > way. Is this the intended behaviour or just an accident of
> > implementation
On 2018-06-03 13:57:26 +1000, Ben Finney wrote:
> (For good reasons, attachments are dropped when messages are distributed
> on the forum.)
By "the forum" you mean Gmane? (I got the attachment over the mailing
list)
hp
--
_ | Peter J. Holzer| we build muc
On 2018-06-03 16:36:12 -0700, bellcanada...@gmail.com wrote:
> On Tuesday, 22 May 2018 17:23:55 UTC-4, Peter J. Holzer wrote:
> > On 2018-05-20 15:43:54 +0200, Karsten Hilbert wrote:
> > > On Sun, May 20, 2018 at 04:59:12AM -0700, bellcanada...@gmail.com wrote:
> > >
mmand line tools), this would be a very
bad idea. Much better to have strange but consistent filenames if you
mount a "foreign" file system. (This is btw also what Samba does,
although it does a spectacularly bad job).
hp
--
_ | Peter J. Holzer| we build much bigger,
On 2018-06-04 16:34:08 +, Peter Pearson wrote:
> On Sun, 3 Jun 2018 20:20:32 +0200, Peter J. Holzer wrote:
> > On 2018-06-03 13:57:26 +1000, Ben Finney wrote:
> >> (For good reasons, attachments are dropped when messages are distributed
> >> on the forum.)
>
On 2018-06-04 22:59:52 +0200, Peter Otten wrote:
> Peter J. Holzer wrote:
> > On 2018-06-04 16:34:08 +, Peter Pearson wrote:
> >> On Sun, 3 Jun 2018 20:20:32 +0200, Peter J. Holzer
> >> wrote:
> >> > On 2018-06-03 13:57:26 +1000, Ben Finney wrote:
>
On 2018-06-05 07:37:34 +, Steven D'Aprano wrote:
> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:
> > On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
> >> I don't know whether or not the Linux OS is capable of accessing
> >> files wi
On 2018-06-05 09:33:03 +1000, Ben Finney wrote:
> "Peter J. Holzer" writes:
> > So we have determined that "the forum" is not the mailing list and not
> > the newsgroup (Jach's message appeared on both with the attachment).
>
> By “the forum” I don&
printf(" %02x", (unsigned char)*p);
}
printf("\n");
}
return 0;
}
Bonuspoints for doing this on an USB stick and then mounting the USB
stick on a Linux system and posting the output there as well.
I'm really curious how MacOS maps those c
Disney would actually let it compound according
> to your theoretical definition, you're a dupe AND a fool. They'd
> figure out some way to reset the counter every five years.
More likely they would prevent such law from being passed in the first
place.
hp
--
_
On 2018-06-10 09:45:06 -0500, Bev in TX wrote:
> On Jun 10, 2018, at 5:49 AM, Peter J. Holzer wrote:
> > On 2018-06-07 12:47:15 +, Steven D'Aprano wrote:
> >> But it doesn't do that. "Pathnames cannot contain NUL" is a falsehood
> >> that progra
On 2018-06-10 15:24:38 +, Steven D'Aprano wrote:
> On Sun, 10 Jun 2018 16:25:24 +0200, Peter J. Holzer wrote:
> > Personally, I would let the author decide what constitutes one work.
>
> Ah yes...
>
> Star Wars, Empire Strikes Back, Return of the Jedi, Phantom Menac
ot;", line 1, in
PermissionError: [Errno 13] Permission denied: '/lost+found/foo'
>>> os.stat("\0")
Traceback (most recent call last):
File "", line 1, in
ValueError: embedded null byte
I think this is worth keeping, and "I couldn't pass th
ally is). The right of a person to be credited could be part of
the former. There is also much less incentive to pretend you wrote
something you didn't if there is no financial advantage, so it may not
be that important.
> there's going to be a lot of corporate bullying.
I don't really
uld use it run a process on
> another host.
Yes.
> But I don't see how to do that, and I was asking if it was possible or
> am I misinterpreting the docs.
It is described on the same page, a little bit farther down:
https://docs.python.org/2/library/multiprocessing.html#using-a-remote-
On 2018-06-11 01:06:37 +, Steven D'Aprano wrote:
> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote:
[Note: I was talking about os.stat here, not os.path.exists. I agree
that os.path.exists (and the other boolean functions) should simply
return false]
> > I think
On 2018-06-11 12:24:54 +, Steven D'Aprano wrote:
> On Mon, 11 Jun 2018 12:31:09 +0200, Peter J. Holzer wrote:
> > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote:
> >> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote:
> >
> > [Not
On 2018-06-13 10:10:03 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" :
> > On 2018-06-11 12:24:54 +, Steven D'Aprano wrote:
> >> It also clearly states:
> >>
> >> All functions in this module raise OSError in the case of
> >>
On 2018-06-11 14:23:42 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" :
> > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote:
> >> Baking a limitation of some file systems into the high-level
> >> interface is simply a *bad idea*.
> >
> &g
On 2018-06-13 23:56:09 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" :
> > POSIX specifies a number of error codes which can be returned by stat():
[...]
> > So none of these is a good choice for the errno parameter of an OSError
> > to be thrown.
>
> Th
t beyond "not ready yet".
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https
interpreter should not use the locale
when parsing Python, and a program producing Python should also ignore
the locale.
You two also seem to be writing about different things when you write
"THE locale". Steven seems to mean the global settings a user has
chosen, you seem to mean the specid
On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
> On 6/23/18 8:28 AM, Peter J. Holzer wrote:
> > On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
> >> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> >>> If I'm in Australia, using the en-AU locale, neverth
On 2018-06-23 16:05:49 +0200, Peter J. Holzer wrote:
> I don't think that's a useful way to look at it. "Locale" in
> (non-technical) English means "place" or "site". The idea behind the
> locale concept is that some conventions (e.g. how to write
On 2018-06-23 12:11:34 -0400, Richard Damon wrote:
> On 6/23/18 10:05 AM, Peter J. Holzer wrote:
> > On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
> >> Once you open the Locale can of worms, EVERYTHING has a locale, to say
> >> you aren't using a
basically just defining the right locale.
Nope. The right rules for almost any file format are much more than the
locale.
hp
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| | | h.
From: "Peter J. Holzer"
--drblskvcly73v23o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-23 08:12:52 -0400, Richard Damon wrote:
> On 6/23/18 7:46 AM, Steven D'Aprano wrote:
> > On Sat, 23
From: "Peter J. Holzer"
--prnws536gtytpj5v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote:
> Either wait for IronPython 3.6, use COM inter
From: "Peter J. Holzer"
--jbhqoow7s7225t6e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-23 16:05:49 +0200, Peter J. Holzer wrote:
> I don't think that's a useful way to look at it. "
From: "Peter J. Holzer"
--p4u6dkqn7e5fhtwt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-23 08:41:38 -0400, Richard Damon wrote:
> On 6/23/18 8:28 AM, Peter J. Holzer wrote:
> > On 2018-0
From: "Peter J. Holzer"
--ngg56dmsr6vcxzs5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-23 12:41:33 -0400, Richard Damon wrote:
> On 6/23/18 11:44 AM, Steven D'Aprano wrote:
> > You'r
From: "Peter J. Holzer"
--b2wbudmypdkmv7il
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-23 12:11:34 -0400, Richard Damon wrote:
> On 6/23/18 10:05 AM, Peter J. Holzer wrote:
> > On 2018-0
From: "Peter J. Holzer"
From: "Peter J. Holzer"
--prnws536gtytpj5v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote:
> Either wait for
ture which has
been implemented in several languages. I haven't checked whether
there are packages on pypi. Shouldn't be too hard to implement if
one needs it.
--
_ | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because
ons are guarantueed to have expired.
In practice this scenario is pretty unlikely: Not only has the client
have to get the same client port, it also needs to get the sequence
numbers (which are 32 bit numbers chosen at random at connection time)
just right.
OTOH, having to
On 2018-06-30 14:01:56 -0700, Dan Stromberg wrote:
> On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer wrote:
> > On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > > If someone else comes along soon after and starts a dif
On 2018-07-01 01:52:12 +, Steven D'Aprano wrote:
> On Sat, 30 Jun 2018 23:49:41 +0200, Peter J. Holzer wrote:
> > The old adage that "security is binary" is utter balderdash.
>
> I think that "old adage" is one of those ones that only people denying
ot; + filename, which will ensure that the correct separator is used).
I think the lazy approach using just forward slashes works because
*Windows* treats slashes in filenames like backslashes (most of the
time), not because Python converts them.
hp
--
_ | Peter J. Holzer| we
301 - 400 of 644 matches
Mail list logo
