text:
Allow additional separator character in variables
Re: [Python-ideas] How assignment...
Possible Enhancement to py.exe...
Mikhail V
19 Nov 2017 19 Nov '17
Python allows underscore character as a separator in variables. This is better than nothing, still it does not make the look much better.
**Proposal**: allow additional separator, namely hyphen character.
**Benefits**: this should provide significant readability improvement. Compared to most syntax change proposals that I remember till now, this seems to have really tangible benefits. So all in all I see it as a significant language improvement. Besides its direct benefit as a good looking separator, it also gives an opprtunity to reduce "camelCase" or similar ugly inclusions in code.
So one can easily compose human-readable variable names e.g.: my-variable figure-shape---width etc.
**Problem**: currently hyphen character is used as a minus operator! The problem is as old as the history of most programming languages, and inherited from initial poorness of character sets. Therefore I don't see a single optimal solution to this.
Solution 1: Use another similar looking character from unicode, for example: U+02D7 (modifier letter minus sign). At the same time IMO it is needed to allow the minus character for the minus operator, namely U+2212 Minus sign. This will allow proper typography of source code. Main benefit of such approach: no breakage of current code base, since new chars are additional to existing ones.
Solution 2: (radical) Disallow hyphen as minus operator, and use only U+2212 Minus sign. I.e. "a-b" would be a variable and "a − b" a minus operation. Advantage: opportunity to correct the improper character usage once and for all. Disadvantage: breakage of current code base + force UTF-8 storage use (consider e.g. editors without unicode support). Thus most probably such solution will cause howl reaching to the sky among users, despite many modern editors allow unicode and custom operator styling, for example to distinguish dash from hyphen in a monospaced editor.
So is my proposal, and as usual urging for constructive conversation. (i.e. proposing to write own language/translator is not constructive conversation)
Cheers, Mikhail
Antoine Rozo
What will the hyphen bring to what is already allowed with underscore? It is not possible to break compatibility with '-' character.
2017-11-19 3:01 GMT+01:00 Mikhail V mikhailwas@gmail.com:
Cheers, Mikhail _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Antoine Rozo
attachment.htm
Greg Ewing
In summary, this proposal seems to be: Give two visually indistinguishible characters different meanings to improve readability.
I'm not sure, but something about that sentence doesn't seem quite right.
-- Greg
Chris Angelico
On Sun, Nov 19, 2017 at 1:01 PM, Mikhail V mikhailwas@gmail.com wrote:
Since you can already avoid camelCase by using snake_case, I'm not sure how much you really gain by adding the hyphen.
While I agree with "my-variable", I don't like the triple hyphen. What's the benefit?
Both of these create extremely confusing situations, where two nearly-identical symbols have completely different meanings. Solution 2 is a massive backward-compatibility break. You're not just disallowing something that's been legal since the language was introduced - you're giving it a completely different meaning. That's basically a non-starter right there.
Solution 1 is at least reasonably plausible, in that you're taking something that's currently a SyntaxError and giving it a valid meaning. There is no code that could be broken by that (AFAIK). However, there's still the problem that you're introducing a marginal benefit and a significant confusion potential; plus, you'd be adding a special case to the Unicode identifier rules, which is not something to be done lightly.
How much benefit do you REALLY get from using hyphens rather than underscores?
ChrisA
Nick Coghlan
On 19 November 2017 at 12:01, Mikhail V mikhailwas@gmail.com wrote:
Regardless of any potential readability merits, backwards compatibility requirements combined with the use of the hyphen character as a binary operator prohibit such a change:
>>> my = variable = 1 >>> my-variable 0
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 19 November 2017 at 12:32, Nick Coghlan ncoghlan@gmail.com wrote:
>>> my = variable = 1
>>> my-variable
Ah, sorry - I now see you addressed the basic version of that.
The alternative of "Use a character that computers can distinguish, but humans can't" isn't an improvement, since it means introducing the exact kind of ambiguity that Python seeks to avoid by using indentation for block delimeters (rather than having the computer read braces, and humans read indentation). The difficulty of reliably distinguishing backticks from regular single quotes is also the main reason they're generally discounted from reintroduction for any other use case after their usage as an alternative to the repr builtin was dropped in Python 3.0, and it's why Python 3 prohibits mixing tabs and spaces for indentation by default.
For anyone tempted to suggest "What about multiple underscores indicating continuation of the variable name?", that's still a compatibility problem due to the unary minus operator:
>>> my--variable 2 >>> my---variable 0
Would hyphens in variable names improve readability sometimes? Potentially, but not enough to live with make binary subtraction expressions ambiguous (hence the consistency amongst almost all current text based programming languages on this point).
On Sun, Nov 19, 2017 at 3:42 AM, Nick Coghlan ncoghlan@gmail.com wrote:
>>> my--variable
>>> my---variable
That seems to be another showcase of misfotune that Python uses hyphen for minus operator. I know it is not language designer's fault, because basic ASCII simply did not not include minus character. But do you realise that the **current** problem you are adressing is that font designers forgot to make the minus character (in monospaced font) distinctive from the hyphen character?
Well, what can I say, I just think it should be a reason to make a collective complain to font providers, but not that you should silently accept this and adopt the language design to someone's sloppy font design.
As an aid for monospace die-hards, to minimise the confusion one could publish a style-guide that recommends to disclose the minus operator (currently hyphen char) in spaces, like a - b, and probably disallow the new proposed hyphen character in the beginning of the identifiers. That would still leave potential for confusion because you cant' force everyone to follow style-guides, but one should struggle to break from this cycle anyway.
Would hyphens in variable names improve readability sometimes?
For reading code, indeed, always and very much. Of course not in case I would be forced to use monospaced font with a similar minus and hyphen. But in that case I am already accepting the level of readability of 12th century, so this would not make things much worse, and I would simply put spaces around the minus operator and try to highlight it with some strong color.
Nick Timkovich
Python does not use U+2010 HYPHEN for the minus operator, it uses the U+002D (-) HYPHEN-MINUS.
In some monospace fonts, there is a subtle difference between U+002D, U+2013 EN DASH, and U+2014 EM DASH, but it's usually hard to tell them *all* apart.
If you want to make a proposal, I'd suggest that you limit it to allowing the U+2010 HYPHEN to be used for names. U+002D simply cannot be changed because it would break billions of lines of code.
On Sat, Nov 18, 2017 at 10:44 PM, Mikhail V mikhailwas@gmail.com wrote:
Mikhail _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Steve Barnes
On 19/11/2017 05:01, Nick Timkovich wrote:
On Sat, Nov 18, 2017 at 10:44 PM, Mikhail V <mikhailwas@gmail.com mailto:mikhailwas@gmail.com> wrote:
On Sun, Nov 19, 2017 at 3:42 AM, Nick Coghlan <ncoghlan@gmail.com
<mailto:ncoghlan@gmail.com>> wrote:
> For anyone tempted to suggest "What about multiple underscores
> indicating continuation of the variable name?", that's still a
> compatibility problem due to the unary minus operator:
>     >>> my--variable
>     2
>     >>> my---variable
That seems to be another showcase of misfotune that Python
uses hyphen for minus operator. I know it is not language designer's
fault, because basic ASCII simply did not not include minus character.
But do you realise that the **current** problem you are adressing is
font designers forgot to make the minus character (in monospaced font)
distinctive from the hyphen character?
Well, what can I say, I just think it should be a reason to make a
collective complain to font providers, but not that you should silently
accept this and adopt the language design to someone's sloppy font
As an aid for monospace die-hards, to minimise the confusion one could
publish a style-guide that recommends to disclose the minus operator
(currently
hyphen char)  in spaces, like a - b, and probably disallow the new
hyphen character in the beginning of the identifiers.
That would still leave potential for confusion because you cant'
force everyone
to follow style-guides, but one should struggle to break from this
cycle anyway.
> Would hyphens in variable names improve readability sometimes?
For reading code, indeed, always and very much. Of course not in case
I would be forced
to use monospaced font with a similar minus and hyphen. But
in that case I am already accepting the level of readability of
12th century, so this would not make things much worse, and I
would simply put spaces around the minus operator and try to highlight
it with some strong color.
How about allowing ¬, (ASCII 172, U+00ac, NOT sign), in variable names as in my¬variable - it has the advantages that:
- it is visually distinguishable even in mono-spaced fonts, (personally I use mono-spaced all of the time when programming but I know that I am a dinosaur), - is actually on many keyboards as a single character, (I don't know of any which actually produce different characters for minus on the numeric keypad and hyphen elsewhere), so can be typed as a single key press, - Is generally unused AFAIK other than in papers about logic, - It is currently unused in the Python language.
This might upset some who would like use it to replace the unary not operator but I suspect that it would be far fewer people than the potential breakages discussed so far.
-- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. http://www.avg.com
Stephan Houben
There is an unfortunate ambiguity in using a character that means "not" as a word separator:
nuke.do¬launch()
"But... I called the method which explicitly did *not* launch the nuke!"
Op 19 nov. 2017 11:05 schreef "Steve Barnes" gadgetsteve@live.co.uk:
>     >>> my--variable
>     2
>     >>> my---variable
collective complain to font providers, but not that you should
hyphen char)  in spaces, like a - b, and probably disallow the new
-- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer.
--- This email has been checked for viruses by AVG. http://www.avg.com
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Richard Damon
On 11/19/17 1:33 AM, Steve Barnes wrote:
There is NO such character in ASCII. ASCII is a 7 bit character set, and no ASCII code has a value bigger than 127.
There are a number of Extended ASCII character sets (hundreds if not thousands). One common one is ISO 8859-1 also called ISO LATIN-1 which has this character at this location, but Extended ASCII is NOT ASCII (Note, it is even produced by a very different standards body). The character also occurs here in ANSI Extended ASCII, but again, this is NOT ASCII.
-- Richard Damon
Bruce Leban
On Sat, Nov 18, 2017 at 8:44 PM, Mikhail V mikhailwas@gmail.com wrote:
It is not a misfortune or even true that Python uses hyphen for minus. The name of the character used in Python is HYPHEN-MINUS. http://unicode.org/cldr/utility/character.jsp?a=002D It is both a hyphen and a minus. And it served double-duty even in ASCII.
A language that requires using characters not present on standard keyboards is unlikely to be successful. Or we would all be programming in APL.
And it's not as if no one every thought of this before. Maybe you've heard of COBOL?
For reading code, indeed, always and very much.
No it wouldn't. You're personal preference is hardly authoritative. I am extremely skeptical that a legitimate usability study would find that record-count is better than record_count.
There are studies that monospace fonts are harder to read than proportionally spaced, e.g., http://journals.sagepub.com/doi/pdf/10.1177/001872088302500303. Yet many programmers use monospace fonts because the advantages -- in our opinions -- outweigh the disadvantages. And the reality is that only my opinion matters when I'm choosing the fonts to display my code in, not yours.
You-know-what-really-would-increase-readability? Allowing-the-use-of-spaces-in-variable-names. As-you-can-see-from-this-example-hyphens-between-words-decreases-readability.
And because spaces between words is mostly not valid syntax currently, this change would be easier to introduce than breaking every single program out there by re-purposing hyphen-minus. But I'm not seriously proposing this because I think the modest benefits are outweighed by the many problems it would introduce.
--- Bruce
Note that Python already allows Unicode characters from class "connector punctuations (Pc)" in identifiers.
No dashes in that, but if you are into that kind of thing, then this⁀is⁀a⁀valid⁀identifier .
Op 19 nov. 2017 08:13 schreef "Bruce Leban" bruce@leban.us:
There are studies that monospace fonts are harder to read than proportionally spaced, e.g., http://journals.sagepub.com/doi/pdf/10.1177/ 001872088302500303. Yet many programmers use monospace fonts because the advantages -- in our opinions -- outweigh the disadvantages. And the reality is that only my opinion matters when I'm choosing the fonts to display my code in, not yours.
You-know-what-really-would-increase-readability? Allowing-the-use-of-spaces-in-variable-names. As-you-can-see-from-this- example-hyphens-between-words-decreases-readability.
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Nikolaus Rath
On Nov 18 2017, Bruce Leban bruce-lcXLltxty2U@public.gmane.org wrote:
Luckily, there is a compromise: use backticks to quote identifiers:
`test mode` = True if `test mode`: `display message`("just a test")
I'm not seriously suggesting that, but I still wonder what people think about it.
I sort of like it, actually. The `(" part is pretty ugly (which is why I included it in the example), but there's no syntax that can completely avoid ugly corner cases. I think in most cases the context would also make it easy to distinguish single quotes and backticks even when they're typographically similar.
Cheers, -Nikolaus
-- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Chris A wrote:
Both of these create extremely confusing situations, where two nearly-identical symbols have completely different meanings.
In reality, hyphen and Minus sign are not even closely similar - Minus is ca. twice as wide, however the citizens of the Monospaced Kingdom may disagree ; ) Though I think its population will dramatically decrease in one or two decades.
Solution 2 is a massive backward-compatibility break.
Yep, although elimination of improper usage is always good thing in longer perspective (and less new additional chars). But I do realise that it is a non-starter.
... a marginal benefit ... How much benefit do you REALLY get from using hyphens rather than underscores?
IMO it's far higher than marginal, at least compared to most syntax proposals I remember. One of the hardest and most important tasks which a programmer is faced, is making readable variable names. Underscores are still one of the MOST ugly things I observe currently in Python syntax. This means, if fixings this, then there will be only "small warts" left (such as e.g. single quotes).
For me, one "cheap" solution against underscores is to use syntax highlighting which grays them out, but if those become like spaces, then it becomes a bit confusing, e.g. in function with many arguments. Also, unfortunately, not many editors allow easy (if any) highlighting customisation on that level. One possible solution is to use a custom font that has hyphen instead of the underscore, but this is not a proper solution, because, well, the character standard is still there, regardless I like it or not. And one should still have an alternative, i.e. *not only one* separator, for example to denote something "special". Also it can enrich some semantical emphasis, e.g.: my-variable_global
For me, one "cheap" solution against underscores is to use syntax highlighting which grays them out, but if those become like spaces, then it becomes a bit confusing, e.g. in function with many arguments. Also, unfortunately, not many editors allow easy (if any) highlighting customisation on that level.
Changing the way editors display underscore-using variable names still seems like a more productive direction to explore than changing the text encoding read by the compiler. The current source code structure is well-defined and unambiguous, so there's no clear benefit to change things at that level, and significant downsides in terms of complexity, forwards and backwards compatibility concerns, and high barriers to pervasive adoption.
By contrast, if the argument for using a different Unicode character is "Editors will reliably display Unicode hyphen characters differently from the way they display minus signs (or vice-versa)", then we can just as easily say "If users are finding the way that text editors display snake_cased_names to be consistently hard to read, then text editors should change the way that they display snake_cased_names (or at least make it easy for users to opt-in to displaying them differently)".
For example, they could decide to replace underscores in variable names for display purposes with hyphens plus the underscore combining diacritic, or the combining macron below:
- https://en.wikipedia.org/wiki/Underline#Unicode - https://en.wikipedia.org/wiki/Macron_below
Then when the cursor was placed inside the variable name, they could revert to displaying those characters as regular underscores.
This kind of editor level modification would also extend itself well to underscores in numeric literals, as there the appropriate pseudo-separator shown when the literal wasn't being edited would be locale dependent.
Changing the way editors display underscore-using variable names still seems like a more productive direction to explore than changing the text encoding read by the compiler.
Indeed that would be a solution. *Would* be. But I don't know of any editor that does that afaik (and they should not in this case, see below).
My view on pros&cons for this solution:
Pros: other languages also have the same issue, so if editors maintainers would agree to compromise and introduce feature of dynamic substitution, that would give users possibility to face-lift other syntaxes as well.
Cons: this feature would make sense if the substitution happens only in those part where it should, namely it should not touch anything in string literals, comment blocks. So the lexer should 'know' where to substitute or not and it is not the same as just passing the internal memory representation through a translation table.
My opinion about this however is based on other principles. Imagine that you are the language designer and I am responsible for the typesetting component of some editor, and we have such a dialogue:
you: "hey Mikhail, we use hyphen for minus operator, now can you please patch the renderer so that our users see the minus instead of hyphen, and please make sure users can also toggle it in real time to see what actual char is there and also make the substitution only in the places where hyphen is used as the operator."
me: "well, I understand your complain, but my renderer already supports Unicode, and I do my best to support typography practices, namely render hyphen as *hyphen*, which is well established for centuries in typography, and defined as a dash of 50% width of the letter "o" and is aligned to lowercase. As well as the Minus glyph which is defined as ca. 110% of "o" width and is aligned to the digits&caps. So you as the language designer should be interested to deliver best practices to the users, and hyphen is way more important for the lexical structure of the written language, than the minus operator. Why would not you just try to solve the issue in a "fair" way?"
By the fair way I understand the way which tends to bring the correct usage of characters back, instead of trying to hide the problem with some patch. Now I can't say what is the least problematic way for Python, but if I were responsible for that, I would base the solution on these principles:
1. The future versions of syntax, ideally, must allow ONLY minus U2212 for the minus operator, and allow hyphens 002D in identifiers. Since it is impossible to the current moment, I must think out the least painful transition. 2. I want users to be able to use underscore as well. Underscore is derived from the mechanical type-writers - to make an underlined text one pushed the carriage back and tipped the underscore to make the line under the text. Currently in digital print it does not make much sense and as a separator looks ugly, but still it not so hopeless. Currently the underscore lies below the font baseline but if one makes it closer to the baseline, then it can be used as a fairly adequate additional separator, so a user would become more ways to denote lexical identifiers. 3. I don't want to break the backward-compatibility but still I am oriented on compliance with typography practices and standards for charcodes. Also I want users who are interested in better UX become the benefits out-of-the-box, without forcing them to tweak the text-editors or writing own translators.
What to do? One option IMO would be to introduce a header in the sources, e.g.: # opt-in: hyphen-minus
Which would tell the parser to toggle the "new" rules, namely U+2212 would be parsed as minus operator and hyphens as part of identifiers. Then users who are aware of benefits and remember monospaced fonts only as unpleasant incident from their youth, can enjoy the beauty of source code without any tweaks, and the only thing they need to do is to bind a key to input the U+2212 sign.
The users who do not want it, just leave this out. Further, I'd add a command-line util that can directly translate to the "old" syntax, in case one want to export a project in old syntax. So one could avoid backward compatibility issue.
That is just one option that comes to my mind.
Another thing which might be important in this regard: Say you want to publish a book about Python. With such syntax you could directly import the code into a DTP software, and you don't need to make any corrections, so it looks almost as a normal English text, and no worries about strange looking minus operators.
On Mon, Nov 20, 2017 at 11:01 AM, Mikhail V mikhailwas@gmail.com wrote:
The future versions of syntax, ideally, must allow ONLY minus U2212 for
the minus operator, and allow hyphens 002D in identifiers. Since it is impossible to the current moment, I must think out the least painful transition.
The least painful transition is to devise an entirely new language, one that is built around whatever rules you like. That way, there's no backward compatibility problem - you pick a new file extension, a new executable name, etc, etc, and nobody gets confused. Of course, since actually building a cross-platform language interpreter is a ton of work, and getting an ecosystem of libraries is even more work, you'll want to make your language compile to Python, but *in your source code* you can use whatever symbols you want.
Since you want U+2212 for subtraction, you probably want to use a few other non-ASCII operators too. U+2044 FRACTION SLASH presents itself as a viable way to create a fractions.Fraction literal. Instead of * and @ for multiplication, you could have U+00D7 and... uhh, I'm not a mathematician, but I'm sure there's an appropriate character.
For the most part, you'd have code that is trivially transformable to and from Python. Start by writing the "my language to Python" translator (it can throw away comments and stuff, the Python code should be considered "object code" rather than "source code"), and then look into the reverse transformation for the benefit of people trying to learn your language.
As long as you don't actually call your language "Python", you're free to do what you like without worrying about compatibility etc.
MRAB
On 2017-11-20 00:20, Chris Angelico wrote:
If we must use U+2212 (MINUS SIGN) for the minus sign, then it's only right that we must also use U+2010 (HYPHEN) for the hyphen.
U+002D (HYPHEN-MINUS) can be left alone, its meaning depending on the programming language, as at present.
Bruce Leban wrote:
It is not a misfortune or even true that Python uses hyphen for minus. The name of the character used in Python is HYPHEN-MINUS.
This is pure demagogy, name it HYPHEN-MINUS-TINYDASH if you like, but what aspect of reality does it change apart of its name? "Hyphen-minus" would make sense for mechanical type-writers. So it is a hyphen, a character used for centuries before typewriters even appeared, and used as such now in 99 percent of medium. Just take some Python sources and count the amount of underscores and minus operators. This will give you an image of how important separators are compared to minus operator. Don't forget also to include cases where variables are written without any separator, but should do so.
I am extremely skeptical that a legitimate usability study would find that record-count is better than record_count.
Oh come on, probably you also want study for emoticons as a separators?
https://en.wikipedia.org/wiki/Underline#Unicode
https://en.wikipedia.org/wiki/Macron_below
If you want to. But a simple a-b test (or is that an a_b test?) of hyphens and underscores would be sufficient.
For anecdotal evidence, I prefer to write git branch names with hyphens, eg "git checkout rosuav/process-check-run". It's not about the typing (tab completion means I don't have to type either form), it's about the way it looks. So there definitely is _some_ advantage here. I just don't think it's significant, not worth the hassle of changing things around. And this is still ASCII-only.
This is pure demagogy, name it HYPHEN-MINUS-TINYDASH if you like, but what aspect of reality does it change apart of its name?
You've gone from making a bad suggestion to trolling.
While you may *think* this character is a hyphen, you're simply wrong. When ASCII was created it was a 7-bit character set limited to 94 printable characters plus space and 33 control characters. The designers explicitly added a single double-duty character for both hyphen and minus, just as they added a single character for single and double quotes rather than left and right quotes. Were they mimicking the typewriter? Maybe they were following the example of Hollerith code which only had uppercase. It doesn't matter. It's not that they were unaware of the different uses or the existence of typographic quotes. Just as monospace fonts were not created because people didn't know about variable width fonts. It is what it is. And pretending other people are idiots is inappropriate.
You can use accent grave as a left quote and apostrophe as a right quote if you want to, but if you insist that Python is living in the dark ages because it doesn't do things *your way* then you're just being rude.
... render
hyphen as *hyphen*, which is well established for centuries in typography, and defined as a dash of 50% width of the letter "o" and is aligned to lowercase. As well as the Minus glyph which is defined as ca. 110% of "o" width and is aligned
False. There is no standard going back centuries defining the widths of the different kinds of dashes. For that matter, there is no standard *today* for what letters and symbols look like. See Doug Hofstadter's great paper on this https://web.stanford.edu/group/SHR/4-2/text/hofstadter.html or the Unicode consortium list of emoji https://unicode.org/emoji/charts/full-emoji-list.html for great examples of the non-standard nature of typography. Heck almost all vendors put cheese on the *hamburger* emoji when obviously it only belongs on the cheeseburger emoji. And Google puts the cheese below the meat which is clearly wrong as the international standard for cheeseburgers puts the cheese on the top.
Just take some Python sources and count the amount of underscores
and minus operators. This will give you an image of how important separators are compared to minus operator.
A non sequitur. Count the number of instances of the letter Z in English vs. the letter E which tells you that Z is unimportant. So let's get rid of it. Of course that may piss off the Polish people since it's the 9th most frequent letter (4.9%) in Polish. While this makes a great story -- see "Meihem In Ce Klasrum" http://www.tau.ac.il/%7Epauzner/funs/simpler.html -- but not a great reality.
That said, no one has argued that a word separator in names is a bad idea and we have two choices: capitalizingEachWord and underscores_between_words. These work well enough that the idea of breaking every single Python program that uses subtraction just because one person believes we are being antediluvian -- without any evidence -- is just not going to happen. (Ooh. See what I did there. I typed two hyphen-minus characters to get an "em dash" and you probably didn't even notice that I was breaking centuries of tradition that the only proper way to write an em dash is with a single piece of metal type.)
If you want to make serious contributions to Python or any other project you need to understand why this is a bad idea.
Yes, if someone insisted that emoticons were superior to underscores as separators and implied I was an idiot for not agreeing with that.
Guido van Rossum
Please kill this thread.
On Sun, Nov 19, 2017 at 7:57 PM, Bruce Leban bruce@leban.us wrote:
False. There is no standard going back centuries defining the widths of the different kinds of dashes. For that matter, there is no standard *today* for what letters and symbols look like. See Doug Hofstadter's great paper on this https://web.stanford.edu/group/SHR/4-2/text/hofstadter.html or the Unicode consortium list of emoji https://unicode.org/emoji/ charts/full-emoji-list.html for great examples of the non-standard nature of typography. Heck almost all vendors put cheese on the *hamburger* emoji when obviously it only belongs on the cheeseburger emoji. And Google puts the cheese below the meat which is clearly wrong as the international standard for cheeseburgers puts the cheese on the top.
-- --Guido van Rossum (python.org/~guido)
On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum guido@python.org wrote:
So the idea is too bad?
Stephen J. Turnbull
Mikhail V writes:
No, the idea is *not* bad, it's just not for Python. As has been true for every one of your ideas for language tweaks that I can recall.
There are *millions* of Python programmers by now. There are more lines of Python being written and read in a day than you could write or read in your lifetime. It's just not practical to *change* the meaning of valid lexical constructs this way, and the rules you want could easily have edge cases that confuse a lot of people. We have a lot of experience with such edge cases, both in Python ("else" clauses on loops, and Python 3 itself, come to mind) and out. We don't like them, as a rule, and introduce them only only when they allow a better expression of something that is quite awkward without them, and preferably only when they express new semantics (ie, something previously impossible).
If it were just one idea, I'd say "suck it up, Mikhail, and get with the programming language". But your ideas are consistently superficially plausible, taking a few seconds of reflection to see that, yes, they could be done, but they are not going to be accepted in mainline Python. The problem with them is that you propose them for Python, not the specific ideas themselves.
The solution is as proposed earlier: create your own language. It shouldn't be excessively hard to write a preprocessor for "mvlang" targeting Python. It has historical precedent: that's how Stroustrup originally implemented C++. It allows smooth interchange of programs with people who know Python, no matter how much you add or change. If, having elaborated all your ideas into this new language, you find yourself unwilling to write in Python, then it's time to publish your language, because other people may feel the same level of attraction to it.
But ... it *will* be a different language, not Python.
Regards, Steve (not speaking for any other Steves, Stevens, or Stephens)
-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Tue, Nov 21, 2017 at 2:51 AM, Stephen J. Turnbull turnbull.stephen.fw@u.tsukuba.ac.jp wrote:
Not every, but many, yes. And there is plethora of proposals less plausible and not for Python. Anyway, I'll stick to python-list better for such topics. BTW, as per Serhiy Storchaka's note:
my·variable myᝍvariable myㅡvariable myⵧvariable myㄧvariable myㆍvariable
^ Is this good idea *for Python*? I mean this is not Python that I knew. I don't know how it is possible. Looks like a result of some unlucky nuclear experment. Might be it will not cause any possible confusion, or less than a hyphen and a minus.
The solution is as proposed earlier: create your own language. [...] language, because other people may feel the same level of attraction to it.
Not much interested in *my own language*. Simple translator for hyphens and minuses I have already made, and I enjoy it.
If the new language thing would happen and gained popularity - it would be the worst scenario - competing syntaxes, CO2 emissions, community splittage, etc. I don't endorse such ideas.
Serhiy Storchaka
21.11.17 05:16, Mikhail V пише:
Yes, it causes less confusion that changing meaning of a minus.
And yes, it can cause confusion if misused. As well as using the following variables:
мyvariable mуvariable myvаriable myvarіable myvariаble myvariaЬle myvariab1e myvariablе
But the name моязмінна doesn't cause any confusion if used in an appropriate context (for example in a lesson for young Ukrainian children). I believe the above dot- and hyphen-like characters don't cause confusion if used as letters in an appropriate language context.
BTW, as per Serhiy Storchaka's note:
my·variable my%Gᝍ%@variable my%Gㅡ%@variable my%Gⵧ%@variable my%Gㄧ%@variable my%Gㆍ%@variable
^ Is this good idea *for Python*?
Given that 5 of 6 show up with the glyph for U+FFFD REPLACEMENT CHARACTER in my client, I'd say not (but then, I can always fix my mail client so don't mind me ;-).
I don't know how it is possible. Looks like a result of some unlucky nuclear experment. Might be it will not cause any possible confusion, or less than a hyphen and a minus.
It depends on how familiar people and tools are with Unicode. For example, after almost clicking on something from "Apple.co.jp" where the "A" is from the Cyrillic block, my mail program now highlights confusables (there's a list at Unicode.org) and also places where languages I don't use are present in the message preview. It really helps in detecting spam! But most people neither have that knowledge, nor the source code to their mail clients and browsers, to help them with those distinctions.
Personally, I think that Python probably should ban non-ASCII non-letter characters in identifiers and whitespace, and maybe add them later in response to requests from native speakers of the relevant languages. I don't know how easy that would be to do, though, since I think the rule is already that identifiers must be composed only of letters, numbers, and ASCII "_". Since Serhiy's examples are valid, we'd have to rule them out explicitly, rather than by reference to the Unicode database. Yuck.
Think of it as evolution in action.
So, languages evolve whether you do it yourself or not. It's not a question of you endorsing the idea. Eventually somebody will write a better language than Python. Why not you?
The problem, if it's similar to an existing one, is the work it creates for the author of the new language. The worst possible case is something like Python 3. IIUC, Guido's opinion now is that looking back, Python 3 was the right thing to do at the time but he's never gonna do that again, too much work on explaining "why Python 3". The question would be, is it right for *you* to do it for a language with your favorite features? I don't say you *should*, just that you *could*.
2017-11-21 12:55 GMT+01:00 Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp>:
Personally, I think that Python probably should ban non-ASCII non-letter characters in identifiers and whitespace, and maybe add them later in response to requests from native speakers of the relevant languages.
That would be quite a backward-incompatible change since such identifiers have been legal since Python 3.0.
I don't know how easy that would be to do, though, since I think the rule is already that identifiers must be composed only of letters, numbers, and ASCII "_".
See: https://www.python.org/dev/peps/pep-313
The identifier syntax is <XID_Start> <XID_Continue>*.
ID_Start is defined as all characters having one of the general categories uppercase letters (Lu), lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers (Nl), the underscore, and characters carrying the Other_ID_Start property. XID_Start then closes this set under normalization, by removing all characters whose NFKC normalization is not of the form ID_Start ID_Continue* anymore.
ID_Continue is defined as all characters in ID_Start, plus nonspacing marks (Mn), spacing combining marks (Mc), decimal number (Nd), connector punctuations (Pc), and characters carryig the Other_ID_Continue property. Again, XID_Continue closes this set under NFKC-normalization; it also adds U+00B7 to support Catalan.
Since Serhiy's
examples are valid, we'd have to rule them out explicitly, rather than by reference to the Unicode database. Yuck.
If we take this thinking to its logical extreme we should ban ASCII 1 and l since they can be confused. Also 0 and O.
Realistically, this is extremely unlikely to be an issue in practice. If you have people making such malignant code changes with checkin permission, you have bigger problems...
Anyway, you can have your linter enforce ASCII or whatever character subset you deem safe.
Serhiy Storchaka wrote:
If those chars are not used at all, then yes :) And I don't recall I was exactly propsing changing meaning of minus
A single word written in local language should not. But its a perfect way to make whole code look like a mess. I think it is very interesting experience to use Cyrillic letters, since many are identical to Latin. So it would not be programming lessons in the first place, but rather constant changing of keyboard layout, and then trying to find unexplainable errors.
If anybody is still worried about this, here is a 29-line proof-of-concept code checker which warns if your source file contains identifiers which are different but look the same.
https://gist.github.com/stephanh42/61eceadc2890cf1b53ada5e48ef98ad1
2017-11-21 19:19 GMT+01:00 Mikhail V mikhailwas@gmail.com:
21.11.17 22:03, Stephan Houben пише:
Ha! I wanted to look at a 29-line code that is able to detect all homoglyphs. But actually it just imports a third-party module. :-(
In any case this is a nice code.
A single word written in local language should not. But its a perfect way to make whole code look like a mess.
Alex Martelli wrote a couple of interesting posts about his experiences with multilingual comments back in the discussion of PEP 263. One of them involved a team from Israel, I think, or maybe South Africa. If you Google site:mail.python.org for Alex and those countries, the thread would probably come up.
Steven D'Aprano
On Thu, Nov 23, 2017 at 02:24:16PM +0900, Stephen J. Turnbull wrote:
Either my google-fu is failing or your memory failed you. I've spent an hour and a half googling, and I'm getting nothing relevant. It doesn't help that Alex was a very prolific poster back in the day.
Hell, I can't even find where PEP 263 was discussed, apart from a brief discussion here:
https://mail.python.org/pipermail/python-dev/2002-July/026449.html
which Alex didn't take part in. (And that was a year after the PEP was first created.)
https://www.python.org/dev/peps/pep-0263/
On 2017-11-24 00:49, Steven D'Aprano wrote:
I think your search might have been hindered by your ability to spell. :-)
Multibyte Character Surport for Python
http://grokbase.com/t/python/python-list/0258fms6xa/multibyte-character-surp...
Steven D'Aprano writes:
Either my google-fu is failing or your memory failed you.
I'm still pretty sure that it's the google-fu, but I confess my google-fu failed me too.
In either case, you have my deepest apologies for the unprofitable hour-and-a-half.
Just for the record, there is also another hyphen, called "soft hyphen", U+00AD. Main difference is that in some software it is an 'interpreted' symbol, and thus may simply disappear from the screen in such software, so it cannot be surely defined as a printable character. OTOH the benefit is that it is 100% present in any font, afaik.
I have found a good technical summary about this character:
http://jkorpela.fi/shy.html
On 21 November 2017 at 21:55, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
We're not going to start second-guessing the Unicode Consortium on this point - human languages are complicated, and we don't have any special insight on this point that they don't. https://www.python.org/dev/peps/pep-3131/#specification-of-language-changes delegated this aspect of the language to them by way of the XID_Start and the XID_Continue categories, and we're not going to change that.
Any hybrid Python 2/3 application or library is necessarily restricted to ASCII-only identifiers, since that's all that Python 2 supports.
We've also explicitly retained the ASCII-only restriction for PyPI distribution names (see https://www.python.org/dev/peps/pep-0508/#names), but that doesn't restrict the names used for import packages, only the names used to publish and install those components. If we ever decide to lift that restriction, it will likely be by way of https://en.wikipedia.org/wiki/Punycode, similar to the way internationalized domain names work, as well as the way multi-phase extension module initialization locates init functions for extension modules with non-ASCII names.
Beyond that, I'll note that these questions were all raised in the original PEP: https://www.python.org/dev/peps/pep-3131/#open-issues
The reference interpreter really isn't the place to experiment with answering them - rather, they're more a question for opt-in code analysis, since that makes it possible for folks to choose settings that are right *for them* (e.g. by defining a set of "permitted scripts" [1], specifying the Unicode characters that should be allowed in identifiers beyond the core set of "Latin" code points allowed by ASCII)
[1] https://en.wikipedia.org/wiki/Script_(Unicode)
Nick Coghlan writes:
We're not going to start second-guessing the Unicode Consortium on this point - human languages are complicated, and we don't have any special insight on this point that they don't.
Agreed. Python, however, is NOT a (natural) human language, and the Unicode Consortium definition of conformance does NOT prohibit subsetting appropriate to the purpose. We DO know more than the Unicode Consortium about Python. For example, I suspect that your catholic appetite for XID in identifiers does not apply to syntactic keywords or names of builtins.
https://www.python.org/dev/peps/pep-3131/#specification-of-language-changes delegated this aspect of the language to them by way of the XID_Start and the XID_Continue categories, and we're not going to change that.
The reference interpreter really isn't the place to experiment with answering them - rather, they're more a question for opt-in code analysis,
I agree about experimentation. I'm not in a hurry, since I've only seen IDEOGRAPHIC SPACE and full-width ASCII break Python programs once or twice in the ten years I've been teaching my students to use it.
We already have a stricter ASCII-only naming policy for the standard library: https://www.python.org/dev/peps/pep-3131/#policy-specification
That's different from placing additional constraints on end-user code, though, as that's where the line between "programming language" and "natural language" gets blurry (variable, function, attribute, and method names are often nouns and verbs in the author's language, and this is also the case for data-derived APIs like pandas column names)
On Thu, Nov 23, 2017 at 4:46 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On 21 November 2017 at 21:55, Stephen J. Turnbull turnbull.stephen.fw@u.tsukuba.ac.jp wrote:
Well, then there is some bitter irony in this, so it allows pretty much everything, but does not allow me to beautify code with hyphens. I can fully understand the wish to use non-latin scripts in strings or comments. As for identifiers, IMO, apart from latin letters and underscore, the first unicode candidate I would add is U+2010. And probably the LAST one I would add.
On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V mikhailwas@gmail.com wrote:
Fortunately for the world, you're not the one who decided which characters were permitted in Python identifiers. The ability to use non-English words for function/variable names is of huge value; the ability to use a hyphen is of some value, but not nearly as much.
Can this thread move to python-list? Or, better, to python-rants-about-unicode-list, to which I don't subscribe?
Carl Smith
Can't we just tell everyone to speak US English, and go back to ASCII? It would be a less painful migration.
-- Carl Smith carl.input@gmail.com
On 23 November 2017 at 14:16, Chris Angelico rosuav@gmail.com wrote:
Well, then there is some bitter irony in this, so it allows pretty much everything, but does not allow me to beautify code with hyphens. I can fully understand the wish to use non-latin scripts in strings or
As for identifiers, IMO, apart from latin letters and underscore, the first unicode candidate I would add is U+2010. And probably the LAST one I would add.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
US English is too broad.
I propose everybody talk like in the "Dallas" TV series and wear mandatory cowboy hats.
(Or was this mail just a dream?)
2017-11-23 15:29 GMT+01:00 Carl Smith carl.input@gmail.com:
On Thu, Nov 23, 2017 at 02:29:43PM +0000, Carl Smith wrote:
I trust you're joking, but it makes me twitchy to see people saying that even in jest, because I've come across folks who *actually do* think that way.
Mikhail V wrote:
In reality, hyphen and Minus sign are not even closely similar - Minus is ca. twice as wide,
If you are using a font that distinguishes them that clearly, and if the human reader is sufficiently typographically aware to notice the distinction. Both of those are big ifs.
And what about handwritten code? I don't know anyone who handwrites hyphens and minuses with precision measured in points.
You already can use "separators" different from the underscore.
Be lucky to distinguish one "separator" from other.
I guess for reference:
exec('a\N{MIDDLE DOT} = 0') exec('\N{BUHID LETTER RA} = 1') exec('\N{HANGUL LETTER EU} = 2') exec('\N{TIFINAGH LETTER YO} = 3') exec('\N{BOPOMOFO LETTER I} = 4') exec('\N{HANGUL LETTER ARAEA} = 5')
On Sun, Nov 19, 2017 at 1:38 AM, Serhiy Storchaka storchaka@gmail.com wrote:
Antoine Pitrou
On Sun, 19 Nov 2017 09:38:17 +0200 Serhiy Storchaka storchaka@gmail.com wrote:
This is going to make for some fun code reviews.
Antoine.
You think that's bad? https://github.com/reinderien/mimic/blob/master/README.md
Abandon all hope ye who use Unicode.
Op 19 nov. 2017 12:06 schreef "Antoine Pitrou" solipsis@pitrou.net:
Python allows underscore character as a separator in variables. This is better than nothing, still it does not make the look much
On 19/11/2017 11:20, Stephan Houben wrote:
Op 19 nov. 2017 12:06 schreef "Antoine Pitrou" <solipsis@pitrou.net
You can get exactly the the same effect by typing command line examples into MS-Word or Outlook and letting people copy and paste to the command line, as both programs "helpfully" and erratically convert double quotes to open/close curly double quote and minus into hyphen, etc. - I have had a large number of cases where this has happened and even start many of my utilities that are deployed to others with a fix parameter issues function that undoes such substitutions in all of sys.argv just to cut down on the number of "it doesn't work" complaints.
python-ideas@python.org
participants (18)


How chemical resistant are composite materials?
A surprising number of applications where composites are used involve occasional or prolonged contact with chemicals. These chemicals can be anything from cleaning agents, acids, alkalis, fuels, hydraulic and brake fluids, de-icers, paint strippers, lubricants, etching chemicals, flue gases and event food and drink.
The resistance of composites to highly reactive chemicals is generally very good, which in turn explains their widespread use in the chemical process equipment industry where it is often difficult to find any other affordable, processable materials capable of withstanding the very harsh conditions.
It is rare for composite components to be attacked as rapidly as some common metals are when placed in contact with acids. A few chemicals that are handled in chemical factories, such as powerful oxidising agents, strong caustic alkalis, bromine and wet chlorine still pose severe problems for general purpose organic matrix resins.
Otherwise, the well-informed selection of materials, in consultation with the suppliers and after reference to the relevant data banks, means that the chemical resistance of composite materials can be tailored to requirements.


The Teradek VidiU is the latest consumer level HDMI H.264 encoder that streams 1080p video at up to 5Mbps over dual band 802.11 a/b/g/n MIMO WiFi, Ethernet, or a 3G/4G USB cellular modem. VidiU is certified by Ustream and the new Livestream platforms, but also includes a generic RTMP interface that enables streaming to any other platform on the Web. Despite the device's compact, light weight chassis, VidiU packs a number of great features including an intuitive OLED display, built-in Li-Ion battery, mic/line input, and iOS monitoring & control via the free VidiU application.
VidiU offers API level integration with the Ustream and new Livestream platforms, which makes streaming to your channel as easy as logging into your account.
Choose the CDN that is right for you. VidiU's generic RTMP interface allows you to stream your live video content to a Wowza server or the platform of your choice at any time.
VidiU offers a free application for iOS that allows you to stream a second video feed to your mobile device for monitoring your live broadcast. Since VidiU acts as its own dual band Access Point, you can choose to connect your iPad or iPhone directly to the device or to your local network.


11.3(1g): Created the release notes for Release 11.3(1g).
11.3(1g): In the Known Behaviors in the 11.3(1g) Release section, removed bug CSCus73592.
11.3(1g): In the Resolved Caveats in the 11.3(1g) Release section, added bug CSCus62709.
In the "Usage Guidelines" section, added information about when GARP flooding is enabled by default.
11.3(1h): Added the content for release 11.3(1h).
11.3(1i): Added the content for release 11.3(1i).
In the "Changes in Behavior" section, improved the clarity of the text.
In the Supported FEX Models section, added N2K-B22HP-P.
In the "Usage Guidelines" section, removed the bullet that began with, "GARP flooding is enabled by default for the Cisco Nexus 93180YC-EX switch…," which was added on May 9, 2016. GARP flooding is now disabled by default for 93180YC-EX switches.
11.3(1g): In the Open Caveats section, added bug CSCvc18574.
Cisco NX-OS Release 11.3 works only on Cisco Nexus 9000 Series switches in ACI Mode.
See Table 2 for a list of modules that are supported on Cisco Nexus 9000 Series switches in ACI Mode.
Table 2 lists the hardware that the Cisco Nexus 9000 Series ACI Mode switches support.
Table 2. Cisco Nexus 9000 Series Hardware.
Note: This switch supports up to 10 I/O modules.
Note: Only the downlink ports 1-16 and 33-48 are capable of supporting SFP1-10G-ZR SFP+.
Note: This power supply is supported only by the Cisco Nexus 93120TX, 93128TX, and 9336PQ ACI-mode switches.
Table 3. Supported FEX Models.
This section lists the new and changed features in this release.
■ For the N9K-C93180YC-EX and N9K-93108TC-EX switches, starting with APIC release 1.3(1) and switch release 11.3(1), storm control interface statistics are cleared when the interface flaps. For other leaf switch models, interface storm control statistics persist across interface flaps.
■ For the N9K-C93180YC-EX and N9K-93108TC-EX switches, starting with APIC release 1.3(1) and switch release 11.3(1), for port channel configurations, the storm control traffic suppression on the aggregated port can be up to two times the configured value. The new hardware ports are internally subdivided into these two groups: slice-0 and slice-1. To check the slicing map, use the command vsh_lc -c "show platform internal hal l2 port gpd" command and look for slice 0 or 1 under the Sl column. If port-channel members fall on both slice-0 and slice-1, the allowed storm control traffic can become twice the configured value because the formula is calculated based on each slice.
■ For any port, only one native 802.1p EPG is allowed, or only one untagged EPG is allowed. It can be one or the other, but not both.
§ On N9K-C93180YC-EX and N9K-93108TC-EX switch hardware starting with the APIC 1.3(1) and Cisco NX-OS software 11.3(1) release, the 802.1p mode EPG packets exit the port untagged.
§ On all other switch hardware prior to the APIC 1.3(1) and Cisco NX-OS software 11.3(1) release, but that is running the most current software, the 802.1p mode EPG packets exit the port tagged as VLAN zero.
o For the other EPGs, packets exit with their respective VLAN tags.
■ When a leaf switch is configured for an EPG to be untagged, for every port that this EPG uses, the packets will exit the switch untagged. If a tagged EPG is configured on the same port, the packets exit the switch tagged.
1. Clear the switch's current configuration by using the setup-clean-config command.
2. Power off the switch by disconnecting the power.
3. Replace the current GEM card with the new GEM card.
4. Power on the switch.
■ This release supports the hardware and software listed on the ACI Ecosystem Compatibility List and the Cisco AVS, Release 4.2(1)SV2(2.3).
■ To connect the APIC (the controller cluster) to the ACI fabric, it is required to have a 10G interface on the ACI leaf. You cannot connect the APIC directly to the N9332PQ ACI leaf switch.
■ The current list of protocols that are allowed (and cannot be blocked through contracts) include the following. Some of the protocols have SrcPort/DstPort distinction.
— UDP DestPort 161: SNMP. These cannot be blocked through contracts. Creating an SNMP ClientGroup with a list of Client-IP Addresses restricts SNMP access to only those configured Client-IP Addresses. If no Client-IP address is configured, SNMP packets are allowed from anywhere.
■ Leafs and spines from two different fabrics cannot be connected regardless of whether the links are administratively kept down.
■ An IP/MAC Ckt endpoint configuration is not supported in combination with static endpoint configurations.
■ An IP/MAC Ckt endpoint configuration is not supported with Layer 2-only bridge domains. Such a configuration will not be blocked, but the configuration will not take effect as there is no Layer 3 learning in these bridge domains.
■ An IP/MAC Ckt endpoint configuration is not supported with external and Infra bridge domains because there is no Layer 3 learning in these bridge domains.
■ An IP/MAC Ckt endpoint configuration is not supported with a shared services provider configuration. The same or overlapping prefix cannot be used for a shared services provider and IP Ckt endpoint. However, this configuration can be applied in bridge domains having shared services consumer endpoint groups.
■ An IP/MAC Ckt endpoint configuration is not supported with dynamic endpoint groups. Only static endpoint groups are supported.
■ No fault will be raised if the IP/MAC Ckt endpoint prefix configured is outside of the bridge domain subnet range. This is because a user can configure bridge domain subnet and IP/MAC Ckt endpoint in any order and so this is not error condition. If the final configuration is such that a configured IP/MAC Ckt endpoint prefix is outside all bridge domain subnets, the configuration has no impact and is not an error condition.
■ Dynamic deployment of contracts based on instrImmedcy set to onDemand/lazy not supported; only immediate mode is supported.
■ Load balancers and servers must be Layer 2 adjacent. Layer 3 direct server return is not supported. If a load balancer and servers are Layer 3 adjacent, then they have to be placed behind the Layer 3 out, which works without a specific direct server return virtual IP address configuration.
■ Direct server return is not supported for shared services. Direct server return endpoints cannot be spread around different virtual routing and forwarding (VRF) contexts.
■ Configurations for a virtual IP address can only be /32 or /128 prefix.
■ Client to virtual IP address (load balancer) traffic always will go through proxy-spine because fabric data-path learning of a virtual IP address does not occur.
■ GARP learning of a virtual IP address must be explicitly enabled. A load balancer can send GARP when it switches over from active-to-standby (MAC changes).
■ Learning through GARP will work only in ARP Flood Mode.
Table 4 lists the open caveats in the 11.3(1g) release.
FEX logs are missing in the output of the show fex detail command.
The events and faults for interfaces are not updated under Ports in the GUI.
The output of some CLI commands display very slowly.
Because ibash is implemented on top of bash, when using ibash for the CLI, the bash behavior is inherited. For example, the sh mod command works in traditional Cisco switches. But when executed on N9K switches in ibash, because bash interprets sh differently, sh mod will not work. Similarly, if there is a clash in the next available options, the TAB key must be pressed twice to get the options rather than once as in other Cisco switches.
In short, the CLI infra for ibash is not exactly the same as the CLI infra for the traditional Cisco switches because N9K ibash is built on top of bash.
FEX-related diagnostic results are missing.
After upgrading TORs from the 1.1(4e) release to the 1.2(1k) release, when the maint-grp-1 set of the TORs are rebooted, there is traffic loss on the virtual machines.
Shared L3out and spine L3out in-band management do not work together.
QosmEgrPkts15min counters are not exported to the interface.
Local endpoints are installed without a "Bounce" flag and point to a remote tunnel instead of a local interface.
Table 5 lists the resolved caveats in the 11.3(1g) release.
IPFIB uses /var/sysmgr for logging. If the partition is full, IPFIB exits without leaving a core.
If a bridge domain is in flood mode, even if the Hot Standby Routing Protocol (HSRP) VMAC times out on a remote leaf, traffic should be flooded. The VMAC can get timed out the remote leaf since it might not see any data traffic with the source MAC as the VMAC.
There are no new resolved caveats in the 11.3(1h) release.
Table 6 lists the resolved caveats in the 11.3(1i) release.
UDP traffic is dropped when bridged through the fabric. This can cause UDP-based protocols to fail. For example, PXE boot clients relying on TFTP to a server in the same bridge domain can fail.
Table 7 lists caveats that describe known behaviors in the 11.3(1g) release.
When configuring the output span on a FEX Hif interface, all the layer 3 switched packets going out of that FEX Hif interface are not spanned. Only layer 2 switched packets going out of that FEX Hif are spanned.
When output span is enabled on a port where the filter is VLAN, multicast traffic in the VLAN that goes out of that port is not spanned.
The show interface command shows the tunnel's Rx/Tx counters as 0.
The show vpc brief command displays the wire-encap VLAN Ids and the show interface .. trunk command displays the internal/hardware VLAN IDs. Both VLAN IDs are allocated and used differently, so there is no correlation between them.
Continuous "threshold exceeded" messages are generated from the fabric.
Switch rescue user ("admin") can log into fabric switches even when TACACS is selected as the default login realm.
An extra 4 bytes is added to the untagged packet with Egress local and remote SPAN.
When the command show ip ospf vrf <vrf_name> is run from bash on the border leaf, the checksum field in the output always shows a zero value.
When an IP address moves from one MAC behind one ToR to another MAC behind another ToR, even though the VM sends a GARP packet, in ARP unicast mode, this GARP packet is not flooded. As a result, any other host with the original MAC to IP binding sending an L2 packet will send to the original ToR where the IP was in the beginning (based on MAC lookup), and the packet will be sent out on the old port (location). Without flooding the GARP packet in the network, all hosts will not update the MAC-to-IP binding.
When modifying the L2Unknown Unicast parameter on a Bridge Domain (BD), interfaces on externally connected devices may bounce. Additionally, the endpoint cache for the BD is flushed and all endpoints will have to be re-learned.
If an endpoint has multiple IPs, the endpoint will not be aged until all IPs go silent. If one of the IP addresses is reassigned to another server/host, the fabric detects it as an IP address move and forwarding will work as expected.
The PSU does not get detected after an OIR device with power input is connected.
The access-port operational status is always "trunk".
An MSTP topology change notification (TCN) on a flood domain (FD) VLAN may not flush endpoints learned as remote where the FD is not deployed.
The transceiver type for some Cisco AOC (active optical) cables is displayed as ACU (active copper).
Any TCAM that is full, or nearly full, will raise the usage threshold fault. Because the faults for all TCAMs on leaf switches are grouped together, the fault will appear even on those with low usage.
Workaround: Review the leaf switch scale and reduce the TCAM usage. Contact TAC to isolate further which TCAM is full.
The default route is not leaked by BGP when the scope is set to context. The scope should be set to Outside for default route leaking.
If the TOR 1RU system is configured with the RED fan (the reverse airflow), the air will flow from back to front. The temperature sensor in the back will be defined as an Inlet temperature sensor, and the temperature sensor in the front will be defined as an outlet temperature sensor.
If the TOR 1RU system is configured with the BLUE fan (normal airflow), the air will flow from front to back. The temperature sensor in the front will be defined as an Inlet temperature sensor, and the temperature sensor in the back will be defined as outlet temperature sensor.
From the airflow perspective, the Inlet sensor reading should always be less than the outlet sensor reading. However, in the TOR 1RU family, the front panel temperature sensor has some inaccurate readings due to the front panel utilization and configuration, which causes the Inlet temperature sensor reading to be very close, equal, or even greater than the outlet temperature reading.
If Backbone and NSSA areas are on the same leaf, and default route leak is enabled, Type-5 LSAs cannot be redistributed to the Backbone area.
Traffic from the orphan port to the vPC pair is not recorded against the tunnel stats. Traffic from the vPC pair to the orphan port is recorded against the tunnel stats.
Traffic from the orphan port to the vPC pair is only updated on the destination node, so the traffic count shows as excess.
If a bridge domain "Multi Destination Flood" mode is configured as "Drop", the ISIS PDU from the tenant space will get dropped in the fabric.
Atomic counters on the border leaf do not increment for traffic from an endpoint group going to the Layer 3 out interface.
Atomic counters on the border leaf do not increment for traffic from the Layer 3 out interface to an internal remote endpoint group.
TEP counters from the border leaf to remote leaf nodes do not increment.
For direct server return operations, if the client is behind the Layer 3 out, the server-to-client response will not be forwarded through the fabric.
With the common pervasive gateway, only the packet destination to the virtual MAC is being properly Layer 3 forwarded. The packet destination to the bridge domain custom MAC fails to be forwarded. This is causing issues with certain appliances that rely on the incoming packets' source MAC to set the return packet destination MAC.
BCM does not have a stats option for yellow packets/bytes, and so BCM does not show in the switch or APIC GUI stats/observer.
Bidirectional Forwarding Detection (BFD) echo mode is not supported on IPv6 BFD sessions carrying link-local as the source and destination IP address. BFD echo mode also is not supported on IPv4 BFD sessions over multihop or VPC peer links.
Traffic is dropped between two isolated EPGs.
The iping command's replies get dropped by the QOS ingress policer.
An overlapping or duplicate prefix/subnet could cause the valid prefixes not to be installed because of batching behavior on a switch. This can happen during an upgrade to the 1.2(2) release.
EPG statistics only count total bytes and packets. The breakdown of statistics into multicast/unicast/broadcast is not available on new hardware.
You must configure different router MACs for SVI on each border leaf if L3out is deployed over port-channels/ports with STP and OSPF/OSPFv3/eBGP protocols are used. There is no need to configure different router MACs if you use VPC.
The default minimum bandwidth is used if the BW parameter is set to "0", and so traffic will still flow.
The debounce timer is not supported on 25G links.
With the N9K-C93180YC-EX switch, drop packets, such as MTU or storm control drops, are not accounted for in the input rate calculation.
For traffic coming out of an L3out to an internal EPG, stats for the actrlRule will not increment.
When subnet check is enabled, a ToR does not learn IP addresses locally that are outside of the bridge domain subnets. However, the packet itself is not dropped and will be forwarded to the fabric. This will result in such IP addresses getting learned as remote endpoints on other ToRs.
■ The Cisco Nexus 9508 ACI-mode switch supports warm (stateless) standby where the state is not synched between the active and the standby supervisor modules. For an online insertion and removal (OIR) or reload of the active supervisor module, the standby supervisor module becomes active, but all modules in the switch are reset because the switchover is stateless. In the output of the show system redundancy status command, warm standby indicates stateless mode.
■ When a recommissioned APIC controller rejoins the cluster, GUI and CLI commands can time out while the cluster expands to include the recommissioned APIC controller.
■ If connectivity to the APIC cluster is lost while a switch is being decommissioned, the decommissioned switch may not complete a clean reboot. In this case, the fabric administrator should manually complete a clean reboot of the decommissioned switch.
■ Before expanding the APIC cluster with a recommissioned controller, remove any decommissioned switches from the fabric by powering down and disconnecting them. Doing so will ensure that the recommissioned APIC controller will not attempt to discover and recommission the switch.
■ Multicast router functionality is not supported when IGMP queries are received with VxLAN encapsulation.
■ IGMP Querier election across multiple Endpoint Groups (EPGs) or Layer 2 outsides (External Bridged Network) in a given bridge domain is not supported. Only one EPG or Layer 2 outside for a given bridge domain should be extended to multiple multicast routers if any.
■ The rate of the number of IGMP reports sent to a leaf switch should be limited to 1000 reports per second.
■ Unknown IP multicast packets are flooded on ingress leaf switches and border leaf switches, unless "unknown multicast flooding" is set to "Optimized Flood" in a bridge domain. This knob can be set to "Optimized Flood" only for a maximum of 50 bridge domains per leaf.
— Set "unknown multicast flooding" to "Flood" for all bridge domains mapped to a leaf.
— Set "unknown multicast flooding" to "Optimized Flood" on needed bridge domains.
There are no new known behaviors in the 11.3(1h) release.
There are no new known behaviors in the 11.3(1i) release.
© 2016-2018 Cisco Systems, Inc. All rights reserved.


The RAW Slim Unrefined Cellulose Filters are made of the purest natural Cellulose Fibers!
Each bag contains approximately 200 Filters.
These filters are perfect for using with your RAW rolling papers, giving you a completely additive free smoking experience. Filters prevent fillers from getting inside your mouth and lessens any harshness.


text:
How to Release a Property Lien
By: Rebecca K. McDowell, J.D.
How to Terminate a UCC
••• Rostislav_Sedlacek/iStock/GettyImages
What Is a Warranty Deed With Vendors Lien?
How to Put a Personal Lien on a Mobile Home Title
How to Replace a Lien Release
A lien is an encumbrance on property that attaches in favor of a creditor to whom the property owner owes money. The creditor must remove the lien once the underlying obligation is paid in full. The method of removal will depend on the type of lien and how it was filed.
Read More: How to File a Property Lien
TL;DR (Too Long; Didn't Read)
A lien must be removed from property once the debt underlying the lien is paid in full. The process for removing a lien depends on the type of collateral and the type of lien, which can include mortgages, judgment liens, UCC liens and car liens.
What Is a Lien?
A lien is a type of security interest a creditor can take in property to secure a debt obligation. A consensual lien is a lien that the borrower agrees to give in exchange for a loan such as a home mortgage or a car loan. A non-consensual lien is a lien that attaches without the borrower's consent and can include tax liens and judgment liens.
When the debt is paid off, the creditor is obligated to remove the lien from the property.
Read More: What is a Judgment Lien?
Removing a Mortgage Lien
A mortgage is a type of lien that is placed on real estate. Anyone who borrows money to buy a new house or refinance an existing home loan will give the lender a mortgage on the house. The mortgage will be released when the loan is fully paid.
A lender can remove a mortgage by filing a document called a Satisfaction of Mortgage or a Discharge of Mortgage (the laws of the state may vary). The satisfaction or discharge should be recorded in the county where the property sits, the same as the original mortgage. Once the document is recorded, the lien is extinguished.
Removing a Judgment Lien
A judgment, or judicial, lien is a lien that attaches to property when the owner is sued and a money judgment is entered against the owner. Many states allow judicial liens, although how they are fixed depends on the state's laws. Once a judgment lien is attached, it remains on the property until removed.
If the obligation is paid, the judgment creditor should file a satisfaction of judgment or similar document as set forth in the court rules of that state or county. Judgment debtors may also be able to remove a judgment lien by filing a bankruptcy case, but their success will depend on how much the property is worth and whether there are other liens attached to it.
Removing a Lien on a Car Title
A lien on a motor vehicle is evidenced by a notation on the vehicle's title indicating that there is a lien. The title will state the name of the lender and sometimes an address. Once the car is paid off, the lien can be removed. Each state's process for doing so may differ, but the gist of the process is that a new title must be issued showing that there isn't a lien.
In New York, for example, the borrower must apply for a duplicate title and include a request for a lien release on the application and a letter from the lender indicating that the lien has been satisfied. The borrower must also provide the original title showing the lien and pay a $20 fee.
Removing a UCC Lien
A consensual lien on personal property that is not a motor vehicle is perfected by filing a UCC-1 Financing Statement as set forth in the Uniform Commercial Code. Every state has adopted some version of the UCC, and if a borrower gives a lender a lien on assets like equipment, inventory, accounts or furniture, the lender will file a UCC-1 Financing Statement, usually shortened to "UCC," with the state where the borrower is located.
When the loan is paid in full, the lender must file a Form UCC-3, which is used to revise a UCC, either to amend, continue or terminate. The box for Termination must be checked. Once the termination statement is filed, the lien is extinguished.
Read More: How to Terminate a UCC
The Washington Post: The Paperwork You Should Receive When Your Mortgage has been Paid in Full
Nolo: What is a Judgment Lien?
Cornell University Law School: Uniform Commercial Code Article 9, Section 9-513
Wolters Kluwer: What You Need to Know About Common Uniform Commercial Code (UCC) Forms
ContractsProf Blog: Uniform Commercial Code: 2016 Legislative Agenda
Wasson Thornhill: Removing a Judgment Lien from the Title to Your Home
New York Department of Motor Vehicles: How to Remove a Lien from a Title Certificate
Legal Beagle: How to Terminate a UCC
Legal Beagle: What Is a UCC Lien?
Legal Beagle: How to File a Property Lien
Legal Beagle: What is a Judgment Lien?
Legal Beagle: How to Release a Property Lien
Legal Beagle: How Do I Get a Title for a Car That Doesn't Have One?
Rebecca K. McDowell is a creditors' rights attorney with a special focus on bankruptcy and insolvency. She has a B.A. in English from Albion College and a J.D. from Wayne State University Law School. She has written legal articles for Nolo and the Bankruptcy Site.

redpajama_set_name: RedPajamaCommonCrawl


Finally have my feet up and am relaxing. Been busy since 11am until…5 minutes ago! Haven't stopped except for dinner. Phew!!
I have very fond memories of making these every year since I was very little. Although, as with most children, I'm fairly sure more of the chocolate ended up in my mouth before it got to the bowl! I remember loving the melting process – which to this day still fascinates me. Although, now I know a lot more about the science of melting and tempering chocolate to get it perfect. I always thought it was a shame to add all the flakes into the glossy chocolate mass sitting in front of me…but I wouldn't say that an hour or so later when I was munching these bad boys down – sneaking a few to my bedroom for later *yes mum, I know you knew*.
…and you would be correct! However, I think it was a wonderful way of getting my mind to think creatively with food, and to discover different consistencies and tastes, even if it wasn't quite correct. Plus sometimes I knew the taste didn't work, but still enjoyed making others try it haha.
I remember those days clearly, and will always be glad I had the opportunity to experiment with cooking. I'm sure its part of what got me to where I am today.
Anyway, away from being sentimental now. I've hopefully got a slightly more relaxed day tomorrow, with only a little bit of baking (yes, I'm obsessed!).
Aw lovely blog post. (and of course I knew!) such a talented photographer as well as such a good cook… That's such a tasteful shot of your nesties! Looking forward to tasting that gluten free pud you've done for Brian.


The heavy scrutiny of North Korea's promises on denuclearization at the September North-South summit in Pyongyang buried otherwise important progress: If the new inter-Korean military agreement signed by the leaders of the two Koreas is implemented, the chances of accidents or miscalculation escalating to full-blown war will decline. But there is an inherent contradiction in the agreement that presents both a serious challenge to its implementation and an opportunity to bolster progress toward a stable peace on the peninsula.
The contradiction is located in the third paragraph of the agreement, which establishes no-fly zones near the military demarcation line that divides the two Koreas for fixed-wing and rotary aircraft, manned or unmanned. These zones are intended to decrease the likelihood that air operations might inadvertently raise tensions or lead to accidental conflict.
Some observers complained that these zones disproportionately affect South Korea by eroding its significant surveillance and reconnaissance advantage over North Korea. The rough mountainous and forested terrain in the demilitarized zone that surrounds the military demarcation line makes aerial monitoring arguably the single most important means of observing military activity on either side, especially for purposes of operational readiness and warning. In agreeing to these restraints, some critics contend that South Korean President Moon Jae-in "risks going too far by lowering allied defenses before North Korea's conventional threat to South Korea, and U.S. troops stationed there, is reduced." Since U.S. forces in Korea operate through a Combined Forces Command jointly with South Korean forces, the new inter-Korean agreement presumably places new restrictions on aerial support for U.S. personnel deployed at bases within the no-fly zones.
Yet there is a more pernicious problem. By limiting aerial observation through no-fly zones, the two sides will be less able to actually verify compliance with many of the restraint measures contained in the agreement, such as the proscription on artillery exercises near the military demarcation line. Essentially, the agreement blindfolds both parties such that they will have difficulty confirming that the other side is adhering to the deal – which could diminish the agreement's ability to deter cheating. Importantly, this limitation portends great difficulty verifying other long-sought military confidence-building measures, such as the withdrawal of deployed artillery pieces or multiple rocket launch systems.
Though South Korea and the United States have satellite and other remote sensing platforms to mitigate data loss from the cessation of aerial monitoring, North Korea does not. Unless it receives such information from a third party such as China, North Korea will be relatively more blind to activity south of the military demarcation line. Pyongyang's inability to verify Seoul's compliance with the agreement could well lead to false claims of cheating or worse by North Korea down the road. The bottom line is that given minimal trust between the two Koreas resulting from failures to implement similar prior agreements, verifying military restraint measures is necessary to actually reduce the probability of escalation.
This contradiction in an agreement intended to reduce military tensions could be a critical flaw, but it also presents an opportunity to establish new means of cooperative monitoring that could fill the information gap for both North and South Korea. The idea would be to establish, under the auspices of the inter-Korean military committee created by the September agreement, a system for observation for purposes of verifying agreed military restraints. For instance, the two could undertake joint air patrols on designated aircraft that would utilize commercially available photo equipment or other methods to provide validated and shared information. Such an approach could help the two sides affirm compliance with limits on military activity in the buffer zones on either side of the military demarcation line, as well as deepen patterns of regular military cooperation. Given the involvement of U.S. and U.N. forces in this theater, multi-party or third-party monitoring may facilitate the necessary information-sharing and extend the potential confidence-building benefits.
In other words, joint monitoring would give both sides the same information and a means of resolving any concerns about compliance. It would also forge a degree of cooperation that could be a building block for future peacebuilding agreements. The existence of the military demarcation zone means the potential for cooperative monitoring has, in theory, always existed. But the recent agreement makes such monitoring especially necessary because the no-fly zones limit independent verification.
Cooperative monitoring is not a new idea, of course. Following diplomatic warming in the early 1990s and again during the era of South Korea's "sunshine" policy in the 2000s, Korean and American experts developed a range of ideas for implementing cooperative monitoring systems to help reduce instability and build confidence on the Korean Peninsula.
These ideas have gathered dust over the last decades, but today it is worth revisiting how they might now help the two Koreas break the cycle of crisis and solidify a lasting peace. The agreement to reduce military tensions has real potential to lower the risk of war and be a building block for lasting peace on the peninsula, but only if this contradiction is managed in a way that provides maximum opportunity for cooperation between these bitter rivals.
Toby Dalton is co-director of the Nuclear Policy Program at the Carnegie Endowment for International Peace, where he works on regional security challenges issues in East and South Asia. He previously served as senior policy advisor in the Office of Nonproliferation and International Security, U.S. National Nuclear Security Administration. Follow him @toby_dalton on Twitter.


text:
Home TV Shows The Magicians Season 6 Coming On Netflix? Release Date, Plot and More
The Magicians Season 6 Coming On Netflix? Release Date, Plot and More
Fans have been entertained by The Magicians, a mesmerizing fictional drama loaded with captivating secrets, since its debut in December 2015. Built on Lev Grossman's book of the same name, this program was created. Because of its excellent plot and scripting, the series has grown in recognition, and fans are eagerly awaiting the release of The Magicians Season 6.
As a group of adolescents is admitted to a hidden institution, they study the specifics of genuine magic, "Magicians" follow them. There's a dark side, though, as they are introduced to a whole new life of terror and dreams. The TV show's elegance is enhanced by the plot's stunning twists and outstanding special effects. "Magicians" has gotten rave ratings on Rotten Tomatoes, and the audience is eagerly anticipating another season filled with suspense and heartbreak. As a result, when can we expect the sixth chapter of "Magicians?" Please see the following:
In January 2021, the fifth season was released on Netflix, and many people have been asking what's going on about The Magicians Season 6. To put it mildly, the news is not that good. Syfy has chosen to terminate the successful show, with its fifth season's thirteenth episode. In the unlikely event that The Magicians season 6 gets revived by some unknown entity, there is no way of knowing when it will be aired. Any guesses on when the next episodes will be released are just that: guesses.
The Magicians Season 6 Plot
Is "The Magicians" discontinued after season 5?
For the sixth season of The Magicians, there is yet to be a storyline, and it's reasonable to anticipate that will not happen anytime soon. Gamble, in an interview, highlighted the good universe they had built and hinted at the prospect of more. According to reports, the next season was in the works, with a detailed blueprint on how it should roll down.
If the series gets renewed for the next season, subscribers will not be disappointed. A number of popular television shows have been rebooted or resurrected in recent years. Considering that is speculation about a possible revival of The Office, it's not out of the question that The Magicians will not come up with another season. In the meanwhile, fans shouldn't anticipate any type of teaser before things progress from being.
Despite five seasons, SYFY came to a decision to discontinue the series. SYFY's ratings plummeted. Regardless of the truth that The Magicians was one of the few remaining written shows on the system, SYFY thought to terminate the show midway through its fifth season. Any significant cliff-hanger was not found in this season. By the time programs reached their 4th and 5th seasons, there was a chance of the series' termination. Particularly when the rankings start to fall. John McNamara along with his co-writers decided to construct an ending that can be possibly made an end of the series in the event of its cancellation. In addition, if the show was renewed, it would be able to continue another season. If a new version is issued, we will be sure to let everyone know as soon as it is available. While we wait for The Magicians Season 6, we'll be sure to keep you updated. Stay tuned for updates on this series. As a refresher, binge-watch the previous seasons on Netflix! This is a series worth binge-watching again.
It's time to say goodbye to this amazing show," said Dave Howe, President, Syfy, and Chiller. "The series has been a pioneer in bringing in a new generation of fantasy fans and we're proud of its impact on the genre. We are grateful to the show's talented and visionary creative team, as well as the cast and crew, for creating a rich, multi-layered world that will continue to entertain and inspire." "It's been a pleasure to work with all of the people at SYFY and Chiller, as well as our incredible fans and partners, to create a series that has been embraced by so many," said John McNamara. "The Magicians has been a wonderful collaboration between the creative team and our fans, and I'm proud of the work we've done together. I'm also grateful to the cast, crew, and the entire cast and crew of the show, who have brought so much love and passion to their characters. I look forward to what comes next." The Magicians has been renewed for a sixth season. The series will continue to air on Syfy, with all episodes available on the Syfy Now streaming service.
TAGS NetflixThe Magicians
X-Men '97, What If…? Season 2, Moon-Knight and other new shows teased by Marvel Studios
Blade Runner Black Lotus Episode 6 Air Date, Leaks, Preview And Spoiler Discussions
What If Season 2 Release Date Confirmed for 2023: Season 3 announced
Riverdale Season 7 Release Date: Is it the Final Chapter of the Series?
Station 19 Season 6 Release Date, Renewal, Expected Plot and Where to Watch
The Chestnut Man Season 2 Release Date; Has Netflix Greenlighted It?


text:
GBGA Requests Judicial Review of UK Gambling Act Verdict
The Gibraltar Betting and Gaming Association (GBGA) has requested a judicial review of the verdict in its recent legal challenge against the UK Gambling Act.
Following its initial failed challenge against the UK Gambling (Licensing and Advertising) Act, the GBGA has requested a judicial review of the verdict passed down by Mr Justice Green earlier this month, claiming that the tax implications of the new legislation contravene Article 56 of the Treaty on the Functioning of the European Union (TFEU).
Whereas the Association´s gripe is based on the same area of European legislation as before, this time it has narrowed down its challenge to just the 15% point of consumption tax that its members will be liable for when they make a profit from a transaction with a UK-based player.
Why a Judicial Review and Not an Appeal?
There are two reasons why the GBGA has chosen a judicial review over an appeal. The first is that the cost of a judicial review is far less than an appeal, and the second is that the GBGA´s original challenge to the UK Gambling Act contained an alternative passport solution that Mr Justice Green found would fail to prove effective or achievable without significant bureaucracy or extra cost .
By eliminating the areas of their case which would be unlikely to succeed, and focusing on the areas of Mr Justice Green´s verdict which are still contentious, the GBGA believes it has a better chance of success. Consequently, the judicial review will be asked to consider specifically whether the point of consumption tax contravenes European law and not the whole of the UK Gambling (Licensing and Advertising) Act.
Has the GBGA Got a Reasonable Argument?
The area of Mr Justice Green´s verdict that the GBGA wants reviewed relates to the measures restricting the freedom to provide services between member states justified on purely economic grounds. In his verdict Mr Justice Green stated that a restriction designed to raise tax would be an economic objective and, as such, inadmissible as a justification .
The GBGA claims that the point of consumption tax is an economic objective and therefore should not be allowed. The Association has also alleged that the tax has the potential to encourage the black market as players leave regulated sites to play on offshore sites where companies not liable for the tax can offer higher value rewards.
In some respects the GBGA has a point. PokerStars has already announced that the rewards offered to UK players will decrease in value from January 1st 2015, and the most extreme consequence of restrictive measures can be seen in Spain – where almost half of the country´s online poker players choose to play on unregulated sites.
What Are the Possible Outcomes?
The aim of a judicial review is not to determine whether the original verdict was right or wrong, but whether it was justified. The review will examine the procedures that were conducted during the original hearing and determine whether the verdict was reached correctly .
If the judicial review determines that Mr Justice Green´s verdict was justified, the judgement will be allowed to stand. If the verdict is unjustified, the review has the authority to quash the original verdict which will lead to the arguments being heard again.
This second scenario could delay the introduction of the point of consumption tax – which is scheduled to be introduced on 1st December – rather than delay the implementation of the UK Gambling Act, which comes into force on 1st November.
Previous Win Tickets to PokerStars Red Spade Open by Revealing Best Poker Tips
Next PokerStars MicroMillions is Back on November 6


text:
Does this year's election show that Italy is racist?
An ugly anti-immigrant election campaign has brought issues around race and migration to the surface. Can Italy make peace with its diverse future?
by Darren Loucaides	/ March 2, 2018 / Leave a comment
Matteo Salvini, leader of Italian far-right party "Lega Nord", in Caserta during his electoral campaign, presents new candidates and his electoral program. Photo: PA
As Italy prepares to go to the polls this Sunday, its top issue is undoubtedly immigration. The increasingly ugly campaign has seen comeback kid Silvio Berlusconi (aged 81) promise to deport 600,000 so-called "illegal immigrants."
His centre-right Forza Italia has allied itself with Lega. Formerly Lega Nord, the party once wanted north Italy to be a separate country, and its candidates have warned that the "white race" is in danger.
Rounding off the coalition that could lead the next government are the far-right Brothers of Italy, whose leader blamed the recent shooting of six Africans by a neo-Nazi in the small town of Macerata on "uncontrolled immigration."
Given how much Italy has borne Europe's brunt of the refugee crisis, it's perhaps no surprise that immigration has become such a hot topic. But does the apparent hard-right shift prove that Italy is xenophobic?
"I wouldn't say that Italy is a racist country," says Antonella Napolitano, communications manager for Civil Liberties in the Digital Age, an organisation responsible for resources like the website OpenMigration.
"Definitely in some respects, there is a latent racism. And I do think that we never properly addressed the aftermath of fascism," she says. "But I think Italy is a welcoming country."
Civil organisations, mayors like Leoluca Orlando in Palermo, who has said that Italy's mayors must become "a megaphone" for refugees, and thousands of ordinary Italians who volunteered during the refugee crisis appear to be proof of this.
On paper, Italy's response to the refugee crisis has certainly been one of welcome compared to stereotypically more tolerant countries like the UK—which has taken a fraction of its fair share.
And yet in a few weeks of campaigning, the Italian right has managed to make immigration a burning issue again. Napolitano believes that this is a result of gross exaggeration and misinformation.
"The numbers of arrivals were of course significant, but nothing to justify words [that were used] like 'invasion'," she says.
At the peak of the refugee crisis in 2015, a million people arrived in Europe, a continent of over 700 million. Compared to Lebanon, whose population of four million absorbed 1.5 million arrivals, this starts to look like small fry. And while studies have…
2679577945e237b0ae2ada7.99777779
Is Johnson seriously heading into an election with this pig's ear of a Brexit deal?
David Hannay / November 1, 2019
There are countless flaws in the Withdrawal Agreement, says a former ambassador to the...
The Prospect Podcast #106: The Brexit election?
Prospect Team / November 7, 2019
Plus why all parties are starting to sound the same
Darren Loucaides
Darren Loucaides is a Barcelona-based writer from London. He used to live in Italy and tweets at @DarrenLoucaides


As a seasoned manager of family wealth, Chris Clarke has seen families break apart when discussions about money take place. "It is a taboo subject, that many parents feel uncomfortable or fear to talk about with their children, until it's too late." Says Clarke.
"Discussions about money and about family rarely happen in the same conversation," Clarke adds. "It's time the two are united and families talk about money in an open environment".
Give kids the gift of financial literacy –the understanding of knowing how money is made, spent, and saved. Also help your children develop the skills and ability to use financial resources to make decisions. Including how to generate, invest, spend, and save money.
Have healthy conversations about money and values. This includes teaching children the true value of wealth, which is so much more than money. The goal is to help them find a clear direction in life and to discover their purpose.
Help children build their own personal power by setting clear boundaries that empower them rather than handing them an easy elevator ride to the top.
Help children define what their own definition of financial freedom means on their own terms.
The issue of financial literacy among children is a growing concern in Canada and several provinces including Ontario and Alberta that are piloting educational programs. These programs are a great start, but parents can help transform classroom teachings into "real life" applications.
In her recent book, True Family Wealth-Love, Money & an Inspired Life, Clarke also offers a way to bring the family together using proven business techniques, such as strategic planning and team building, to grow and preserve both financial and personal wealth now and for future generations.
Chris Clarke draws on 30 years of experience as CEO and Co-owner of First Affiliated Holdings Inc. She is a Chartered Professional Accountant, Trust and Estates Practitioner, and a Registered Financial Planner. Clarke is also certified as a Family Facilitator by the Canadian Association of Family Enterprise.